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REMARKS 

On pages 2 and 3 of the Office Action , the 
Examiner objected to the specification for not providing 
antecedent for the terms "first software," "second 
software," "third software," "fourth software," "fifth 
software," "sixth software," and "seventh software," as 
used in certain of the claims. 

However, the specification does provide 
antecedent for these terms. Indeed, Figure 8 and the 
description corresponding thereto discloses and describes 
the software that is the subject of claims 15-2 0. 

Purely as an example and in no way limiting to 
the interpretation of these claims, the first software of 
claim 15 relates to SOI and its written description, the 
second software of claim 15 relates to S02 and S03 and 
their written descriptions, the third software of claim 
15 relates to S04 and its written description, the fourth 
software of claim 15 relates to S06 and S07 and their 
written descriptions, and the fifth software of claim 15 
relates to S08 and its written description. 

Also, and again purely as an example and in no 
way limiting to the interpretation of these claims, the 
sixth software of claim 16 relates to S03 and its written 
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description. (Claim 16 has been amended to remove 
reference to seventh software.) 

Further, and again purely as an example and in 
no way limiting to the interpretation of these claims, 
the sixth software of claim 17 relates to the software 
executed by the engine of the unit 18 shown in Figure 5. 
The written description of this software is provided in 
paragraphs 0047 through 0051 of the substitute 
specification. 

Claim 18 merely provides that the invention of 
claim 15 operates in connection with a network as shown 
in Figure 1 and the written description corresponding 
thereto . 

Claim 19 merely provides that the invention of 
claim 15 operates in connection with an externally 
connected bus as shown in Figure 2 and the written 
description corresponding thereto. 

Claim 20 has antecedent in the specification in 
a similar manner. 

One more comment is appropriate. The use of 
the qualifiers "first,' "second," etc. in front of the 
word "software" in these claims is merely for convenience 
so that the various software can be easily and succinctly 
distinguished. One of ordinary skill in the art will 
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understand that, since the specification provides 
antecedents for the various software recited in the 
claims, and since the various software described in the 
written description are distinguished among themselves, 
the written description accordingly provides antecedent 
for the software when they are referred to in the claims 
as "first software," "second software," etc. 

Thus, for the reasons given above, the written 
description provides antecedent basis for claims 15-20. 

On page 3 of the Office Action , the Examiner 
rejected claims 15-20 under 35 U.S.C. §112, first 
paragraph, as failing to comply with the written 
description requirement. However, as should be clear 
from applicants' response to the Examiner's objection on 
page 2 of the Office Action, claims 15-20 do comply with 
the written description requirement 

On pages 3-6 of the Office Action , the Examiner 
rejected claims 15-20 under 35 U.S.C. §112, second 
paragraph, as being indefinite. 

Particularly, the Examiner objects to the use 
of "first software," "second software," etc., asserting 
that such terms lack standard meaning. 

However, as the Examiner will appreciate, 
describing portions of a program in terms of its 
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constituent software parts is common practice. Indeed, 
when applicants searched issued patents in the patent 
database of the USPTO using the search terms "first 
software" and "second software," applicants got hits on 
1288 patents that use these terms. Moreover, these terms 
are also clear in the context of the present patent 
application as demonstrated above. 

Therefore, claims 15-20 are definite under 35 
U.S.C. §112, second paragraph, in their use of "first 
software," "second software," etc. 

The Examiner on pages 4-6 raised additional 
objections to claims 15-17. 

The Examiner in lines 9-12 on page 4 of the 
Office Action quotes a portion of claim 15 . However, 
applicants cannot find this quoted portion in claim 15. 
Moreover, applicants have reviewed claim 15 and it is 
grammatical, so applicants are unable to identify the 
Examiner's objection. 

If the Examiner is objecting to the fourth 
software clause of claim 15, this clause is grammatical. 
To paraphrase, the fourth software references a 
determination- rule- storage unit and determines whether 
said input/output data is invalid data, and 
determination-rule-storage unit stores rules for 
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determining whether said input/output data is invalid 
data. The penultimate and ultimate clauses of claim 15 
make it clear that the determination- rule -storage unit 
stores determination rules that correspond to user 
attributes and that the fourth software determines 
whether said input/output data is invalid data in 
accordance with said determination rules that correspond 
to user attributes. 

Accordingly, claim 15 is grammatical. 

The Examiner has a number of objections to 

claim 16 . 

First, in line 20, page 4 through line 3 of 
page 5 of the Office Action, the Examiner quotes language 
that applicants cannot find in claim 16. Claims 16 does 
recite "wherein said sixth software determines 
authorization of the user to use said computer before 
execution of said third and fourth software." However, 
the term "said sixth software" does have antecedent basis 
in the claim. 

Second, the Examiner objects to the word "this" 
in the claim. However, applicants cannot find this word 
in the claim. 

Third, the Examiner asserts that the claim is 
either incomplete or inconsistent because the limitation 
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of "acquiring attribute information" is a necessary 
element of the claim. However, the sixth software does 
not require attribute information to determine whether 
the user corresponding to the ID information has 
authorization to use the computer. As disclosed in the 
present application, if the ID of the user is not in the 
database, the user is not authorized. 

Accordingly, claim 16 is definite. 

The Examiner objected to the term "said 
operation is unusual" in claim 17 as lacking antecedent 
basis. Accordingly, claim 17 has been amended to 
overcome the objection. 

On pages 6-9 of the Office Action , the Examiner 
rejected claims 15-26, and 28 under 35 U.S.C. §102 (e) as 
being anticipated by Rothermel. 

Rothermel describes a network security device 
management system 100 that includes a security policy 
manager device 110 able to communicate with a supervisor 
device 120. The supervisor device 120 is associated with 
a network security device (NSD) 130. The NSD 130 
protects a trusted device 220 from an external device. 

The NSD 130 stores information about the 
supervisor device 120 (e.g., the device's network 
address) with specific security policy information 133. 
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The NSD 13 0 also stores any required access information 
(such as a unique password which the supervisor device 
120 must provide in order to gain access to the NSD 13 0) 
along with device access information 134. The NSD 130 
implements a security policy by executing software 132 
and using the stored specific security policy 
information. An example of a security policy is the 
following: outgoing FTP connections are allowed only from 
certain information services associated with IP addresses 
220.15.23.52, 220.15.23.53, and 220 . 15 . 23 . 97 . 

Figures 5A-5D provide an example of a GUI 
displaying a hierarchical view of a supervisor device, a 
NSD, and corresponding configuration and network 
information. As shown in Figure 5A, various information 
about the supervisor device and the NSD can be displayed 
textually (e.g., the IP address, connection status, and 
phone number) . Figure 5B provides a graphical view of 
real-time connections, Figure 5C indicates various users 
associated with specific IP addresses, and Figure 5D 
includes information about IP addresses and ports which 
are currently blocked. 

As shown in Figure 6, the NSD software 
components include a packet filter engine 615 and 
authentication software 640. The packet filter engine 
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615 implements the security policy for the NSD. A 
network security information logging component 66 0 
provides network security information to the supervisor 
device . 

Figure 7 is a flow diagram of a routine 700 
executed by the NSD. The routine 700 implements a 
specific security policy for the NSD by monitoring 
network information passing between devices of interest 
(e.g., between an external device and a trusted device), 
by applying security policy filter rules, and by 
generating network security information about events of 
interest . 

At 705, the NSD loads its software. At 710, 
the NSD loads NSD-specific network packet filter rules 
that will be used to implement the specific security 
policy. At 715, the NSD monitors any passing network 
information. At 720, when network information packets of 
interest are detected, the NSD filters the network 
information packets. At 725, the NSD generates network 
security information about any events of interest . At 
73 0, the NSD responds to management messages from the 
supervisor device. At 790, the NSD determines whether to 
continue monitoring network information packets . 
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Figure 8 shows the network packet filtering at 
720. The NSD determines whether network information 
packets match one or more security policy filter rules, 
applies filter rules to determine what actions to take 
for the packets, and takes the action. At 805, the NSD 
receives information about the network information 
packets of interest. At 810, the NSD determines whether 
the packets match a filter rule. If so, the NSD at 815 
applies the filter rule to determine an action to be 
taken for the packets. If the NSD determines at 810 that 
no filter rule applies, the NSD at 820 determines a 
default action to be taken for the packets. Default 
actions include denying passage of all packets that are 
not explicitly approved, blocking spoofing attacks, 
blocking port space probes, and blocking address space 
probes. At 825, the NSD takes the determined action on 
the packets. 

Independent claim 15 

Applicants' Argument - There are at least two 
distinctions between Rothermel and independent claim 15. 

First , Rothermel fails to disclose acquiring 
attribute data that is stored in a user-information- 
storage unit for all users and that corresponds to ID 
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information associated with input /output data that is 
input or output over a network. 

On page 7 of the Office Action, the Examiner 
asserts that network addresses and group information are 
user attributes. 

Rothermel defines a network address as an IP 
address. (Column 1, lines 36-45.) Examples of IP 
addresses are given in column 10, lines 36-42. As can be 
seen, these network addresses neither identify a user nor 
provide any attributes about the user. 

The term "group information" is not used in 
Rothermel. Therefore, it is difficult to determine what 
the Examiner means by this term. Column 12, line 48 
through column 13, line 7, and particularly column 13, 
lines 5-7, seem to indicate that groups of users can be 
defined with different levels of access privileges. 
However, these access privileges, their structure, and 
the manner in which they are implemented are not defined 
in Rothermel . 

In making this assertion, the Examiner points 
to several sections of Rothermel. 

Column 7, lines 50-53 merely state that the NSD 
implements a security policy by executing software and by 
using stored policy information. However, there is no 
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disclosure in this portion of Rothermel that user 
attributes are stored in a user-information-storage unit 
for all users having authorization to use a computer. 

Column 2, lines 15-23 state that the decision 
to take different actions can also be based on additional 
factors such as the direction of information flow, or on 
the basis of the sender or the intended recipient of the 
information. Again, there is no disclosure here of 
associating user attributes with user identities. 

Column 4, lines 49-56 state that security 
policy templates define default network information 
filtering rules and use defined aliases to represent 
various devices. Thus, aliases represent devices rather 
than users and certainly are not user attributes 
associated with user identities. 

Finally, Figure 5C shows various users 
associated with specific IP addresses. As discussed 
above, an IP address is not an attribute of a user. 
Rather, if it is an attribute an attribute at all, it is 
an attribute of a network device . 

Moreover, Rothermel does not disclose that the 
user's ID is used to acquire an IP address from the table 
of Figure 5C. Rothermel does show in connection with 
Figure 3B that IP addresses can be used in rules such as 
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rule 316 to the effect that outgoing FTP connections are 
allowed only from the network devices associated with 
predefined IP addresses. 

However, Rothermel never describes any use of 
Figure 5C or any instance in which a user is identified 
and an attribute of the user is looked up from a table or 
other memory unit on the basis of the user ID. 

Accordingly, because Rothermel fails to 
disclose acquiring a user ID and using that ID to look up 
an attribute of the user from memory, independent claim 
15 is not anticipated by and is not unpatentable over 
Rothermel . 

Second , Rothermel fails to disclose determining 
whether input/output data is invalid based on rules that 
are stored in a determination-rule-storage unit and that 
correspond to user attributes. 

Rothermel does describe rules as asserted by 
the Examiner on page 7 of the Office Action. However 
none of the rules described in Rothermel are based on 
user attributes that must be distinct from user IDs 
because the attributes are acquired from memory based on 
user IDs. 

For example, rule 316 of Rothermel as discussed 
above does not correspond to a user attribute. Rather, 
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rule 316 is based on an IP address, which at most is a 
device attribute and is not a user attribute. 

Rule 301 complements rule 316 and specifies 
that outgoing FTP connections are allowed only from 
network elements defined as being within the Information 
Services alias. As can be seen, rule 3 01 does not 
correspond to a user attribute. 

Indeed, Rothermel describes no rules that are 
based on user attributes. 

In making the assertion that Rothermel 
discloses rules that are based on user attributes, the 
Examiner points to several sections of Rothermel. 

Column 1, line 56 through column 2, line 5 
names various network services and protocols, none of 
which apply rules that are based on user attributes. 

Column 7, lines 50-53 merely state that the NSD 
implements a security policy by executing software and by 
using stored policy information. However, there is no 
disclosure in this portion of Rothermel of rules that are 
applied based on user attributes. 

Column 2, lines 15-23 state that the decision 
to take different actions can also be based on additional 
factors such as the direction of information flow, or on 
the basis of the sender or the intended recipient of the 
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information. There is no disclosure in this portion of 
Rothermel of rules that are applied based on user 
attributes . 

Column 11, lines 46-58 describe Figures 3G and 
3H as providing examples of information related to events 
of interest and of network security information of 
interest. Figure 3G is characterized as showing a GUI 
for specifying how to generate network security 
information, such as for a filter rule or service, and 
how to notify indicated users or devices of the network 
security information. Figure 3H is characterized as 
showing various configuration information for an HTTP 
proxy service, including types of information which may 
be denied passage as well as may be logged. There is no 
disclosure in this portion of Rothermel of rules that are 
applied based on user attributes. 

Column 4, lines 49-56 state that security 
policy templates define default network information 
filtering rules and use defined aliases to represent 
various devices. Thus, aliases represent devices rather 
than users and certainly are not rules that are applied 
based on user attributes. 

Finally, Figure 5C shows various users 
associated with specific IP addresses. As discussed 
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above, an IP address is not an attribute of a user and is 
not a rule that is applied based on user attributes. 

Accordingly, because Rothermel fails to 
disclose rules that are based on user attributes, 
independent claim 15 is not anticipated by and is not 
unpatentable over Rothermel. 

On page 11 of the Office Action , the Examiner 
answers applicants' argument that Rothermel does not 
disclose the third software of independent claim 15, i.e. 
software that acquires attribute data corresponding to ID 
information in input/output data from a memory that 
stores attribute information for the users. 
Specifically, the Examiner asserts that the claims do not 
recite associating attributes with user ids. 

Applicants cannot agree. 

The only way that the attribute information can 
be stored for users is to stored the information 
according to user name or some other id for the user. No 
other arrangement would make sense. 

Moreover, independent claim 15 recites that the 
third software acquires the attribute data based on the 
ID information that identifies a user. In order to 
acquire that attribute data from the user- information - 
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storage unit, the attribute data must be stored in 
association with the user ID information. 

Accordingly, for all of these reasons, these 
features that distinguish independent claim 15 over 
Rothermel as previously and currently argued by 
applicants are based on limitations of independent claim 
15. 

On page 12 of the Office Action, item (ii) , the 
Examiner insists that aliases such as IP addresses 
include attribute data. 

However, this insistence is not correct for 
several reasons. 

First, if an IP address identifies the user, 
then the IP address is the ID and not the attribute. 

Second, IP addresses are routing numbers that 
identify machines, not users, and, therefore, cannot be 
user attributes. That is, an IP address is a numerical 
identification and logical address that is assigned to 
devices participating in a computer network. An IP 
address is typically stored in binary form, but they are 
usually displayed in human-readable notations, such as 
2001 :db8: 0:1234:0:567:1:1 (this form is provided by 
version 6 of the Internet Protocol) . 
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Third, Rothermel does not explain Figure 5C and 
does not state that the IP addresses associated with user 
names are used for anything, and certainly Rothermel does 
not disclose that the user name is used to acquire an IP 
address which is used to acquire a rule. Therefore, the 
IP address cannot be an attribute of independent claim 
15. 

Fourth, the present application excludes IP 
addresses from being user attributes. For example, 
paragraph 0005 of the substitute specification states 
that the use of IP addresses creates problems. Paragraph 
0008 of the substitute specification then discloses that 
the use of user attributes overcomes these problems. 
Thus, the present application states that user 
attributes, not IP addresses, are used to access rules. 

Moreover, paragraph 0042 of the substitute 
specification discloses that general rules determine 
invalidity regardless of user attributes and are based on 
IP addresses. Paragraph 0042 contrasts these rules with 
attribute rules that determine invalidity based on user 
attributes such as department or work position. 

Therefore, by definition of the present 
application, an IP address cannot be a user attribute. 
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On page 12 of the Office Action, item (iii) , 
the Examiner again asserts that applicants argue features 
that are not in independent claim 15. 

However, as discussed above, all argued 
features are in the corresponding claims. 

On page 13 of the Office Action , the Examiner 
insists that applicants argument that an IP address is 
not an attribute is not supported by rationale. 

However, discussed above is more than adequate 
rationale to show that an IP address is not a user 
attribute . 

Accordingly, independent claim 15 is not 
anticipated by and is not unpatentable over Rothermel . 

Because independent claim 15 is not anticipated 
by and is not unpatentable over Rothermel, dependent 
claims 16-19 are not anticipated by and are not 
unpatentable over Rothermel. 

For similar reasons, independent claims 20-23 
and 28 are not anticipated by and are not unpatentable 
over Rothermel . 

Because independent claim 23 is not anticipated 
by and is not unpatentable over Rothermel, dependent 
claims 24-26 are not anticipated by and are not 
unpatentable over Rothermel. 
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On page 10 of the Office Action , the Examiner 
rejected claims 19 and 27 under 35 U.S.C. §103 (a) as 
being unpatentable over Rothermel . 

However, since independent claims 15 and 23 are 
not unpatentable over Rothermel, dependent claims 19 and 
27 likewise are not unpatentable over Rothermel. 
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CONCLUSION 

In view of the above, the claims of the present 



application patentably distinguish over the art applied 
by the Examiner. Accordingly, allowance of these claims 
and issuance of the present application are respectfully 
requested. 



The Commissioner is hereby authorized to charge 



any additional fees that may be required, or to credit 
any overpayment, to account No. 501519. 



Respectfully submitted, 

Schiff Hardin LLP 
6600 Sears Tower 
233 South Wacker Drive 
Chicago, Illinois 60606 
(312) 258-5500 
Customer No. 26574 
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